As it is generally known, in the area of graphical user interfaces, hierarchical rendering of object sets is a ubiquitous means of automatically grouping objects, signifying ancestry (i.e. responses), nested taxonomic context, authorship, physical storage structure (e.g. directories), date/order of composition or arrival, markup language linkage, and other conceptual relationships between objects. Manual techniques also exist for creating and editing hierarchies of objects, where embedded or other automatic means of association are absent or insufficient.
Mouse operations used to manipulate hierarchically nested objects (e.g. drag and drop) are well-known, and are standardized across computer hardware, operating systems and software systems. When composition, revision and delete volatility is predictable, object hierarchies in existing systems are generally well-behaved and more or less static. However, problems arise from the use of the following object editing operations that can damage object hierarchies irreparably:
1. Deleting parent objects. Whether they are “founding objects” or intermediate nodes in the hierarchy, once objects are deleted from a hierarchy, the result is generally either a default rendering of a collapse, or breaking of a descendant tree.
2. Arrival or composition of ancestor objects after their descendants. For example, this problem may arise when a child electronic mail message arrives before a parent message, when a portion of a Web discussion forum is copied to another location, or when a Web page is moved from its original position in a Web site. Most semantic linkage implies an order of object inception, and is accordingly organizes objects from parent object (oldest) to child object (youngest). When a late arrival (e.g. via network latency) or composition (corpus addenda) occurs, object ancestry becomes confused at best. While there currently exist categorical techniques for reorganizing the affected objects, existing approaches all require human intervention.
3. Forwarding objects. Sending objects (e.g. messages) to other users is generally done out of any originating hierarchical context, even though a sending user may intend to forward an entire hierarchy, or cause it to be extended through the forwarding operation.
4. Modification of hierarchy rules. If a different categorization or means of grouping is performed on an object set, the prior hierarchy is discarded. There is generally no way to roll back such changes.
For the above reasons and others it would be desirable to have a new system that maintains static linkage structures across all types of object and/or metadata operations, as well as membership in an arbitrary number of hierarchies for any given object in a set of objects.